Management 3.0 - Grow structure
組織構造を成長させることについて
まとめ
コミュニケーション不全は一般的
コミュニケーションに必要な適切なフィードバックがしばしばなされていないため
組織は複雑なネットワーク
コミュニケーターには 9 つのケイパビリティがあり、人によって強さが違うため
社会的コミュニケーションネットワークにおける多くの効果があり、均質化効果が特に興味深い これにより文化や流行が生まれる
コミュニケーションの最適化には、接続性の調整や競争と協力を伴うことが必要
最適化されたコミュニケーションのひとつが、自己触媒的なチーム
組織の構造がコミュニケーションの最適化に貢献する
フラクタル的な構造 (どの規模でも変わらないパターン) が効果的で、少数のルールで達成できる
スケールアップよりスケールアウトの方が適応的で良い
適切な組織構造は環境や組織規模などに応じて異なるので、それに合わせて組織構造を変えるべし
チームの境界は明確にすべし
チームの人数は 3 ～ 7 人がおすすめ
チームは、価値提供の単位 (社内向けにも社外向けにも) で組む
チームのスタイルは (機能組織 or 機能横断組織) × (DP1 or DP2) の 4 通り
一般論としては、機能横断組織が機能組織より良く、DP2 の方が DP1 より良い
マネジメントレイヤーは、関心の分離を意識して設置する 組織内の情報は透明に、人のつながりをつくる
Chapter 12 : Communication on Structure
ある人にとっては問題でも、他の人にとってはフィーチャーかもしれない
両者が適切に情報を交換し、両者が同じ意味を割り当てていることに同意した場合のみがコミュニケーション
どの組織でもコミュニケーション不足が一般化している
コミュニケーションは、情報、人間関係、フィードバックの 3 つの現象の関数 (筆者の関係)
コミュニケーションについて最善を尽くすために、組織はネットワークであるという認識から初めて、システムの構造を理解する必要
社会集団における均質化が、文化や流行、ファッションを共有する仕組み
均質化によるコピーは、3 回で効果を失う (= 知人の知人の知人まで)
多くの組織では隔たりは 3 階層までだと仮定すると、均質化は十分に効果を発揮できる
システム内の接続数は調整が必要 (多すぎても少なすぎてもだめ)
接続数が多い場合、自身が処理する情報を一定に保つために、積極的に情報を無視するようになる
情報が多くても適切にフィルタリングできていれば問題はない
チームが情報をフィルターしたり協働する方法を学ぶために時間が必要 → 頻繁にチーム構造を変えてはいけない
従業員同士は競争相手でもあるが、利己的な判断で協力しあう
複雑なシステムのエージェントが協働するとき、サブシステムを構成しがち ← モジュール性
4 つのグループ形成方法
Concocted group : 外部からの力で計画的に作成
マネジャーはこのグループの形成に責任があるが、チームの編成や協働が難しい可能性 → チームに委任する方法もある
Founded group : 自分たちで計画的に作成
Self-organized group : 自分たちで、計画外あるいは緊急の方法で作成
Circumstantial group : 外部の状況から、緊急に作成される
グループをチームと呼ぶには 2 つのことが重要
共通の目標がある
グループの境界がある
チームの境界があいまいだと、人々はチームとして行動できない
チームの境界が狭すぎたり、開きすぎたりしていないこと
システム内部の接続にも、システムの境界にも、適応型バランシング機能が必要
Demarco と Lister が言う “jelled” チームや、アジャイルエキスパートの Jeff Sutherland がしばしば言及するソフトウェアチームの 「超生産性」 はこれで説明できるかも 複雑系におけるパターンは出現する事象 (emergent event)
チーム形成とコミュニケーションにおいて、パターン (空間的あるいは時間的) が発生するのは確かなこと
パターンに目的を持たせるためには、マネジャーが自己組織化を通じてパターンが発生するようにしなければならない
パターンは規模に対して不変なので、小規模でうまくいくパターンは大規模でもうまくいく
システムの規模
規模を大きくする方法は 2 種類
大きくなることで脆弱性が小さくなる (正のフィードバックループ) が、適応性が小さくなる (負のフィードバックループ)
複雑さの観点からは、スケールアップよりはスケールアウトの方が優れている (適応性が高いので絶滅しにくい)
Chapter 13 : How to Grow Structure
環境、製品種別、組織規模、人の 4 つの変化が組織構造の変化を生み出す
「最良の」 組織構造は、組織の生きる環境によって違ってくる
ゆえに、マネジャーは、継続的な構造変化のための組織能力に焦点を当てるべき 組織の変化の 2 番目の要員は製品の種類
3 番目の要因は組織の規模
最後の推進力は人々
時間とともに変化しない事業は、誰にも価値がないものに多大な労力を生み出すようになっていく
組織に利用可能なリソースがあるという理由だけで、新しい仕事が生み出されうる
まずは専門化 (specialization) を考える
専門家のチームは、ジェネラリストのチームよりも生産性が高い
誰もが何でもやるチームではなく、それぞれの専門性を持つ
次に一般化 (generalization)
専門化には問題がある : ボトルネックになり得たり、得意なことしかしないことで停滞を招いたり
こういう人により、ボトルネックの問題を解消し、柔軟性を持つチームになる
組織の適応性を高めるために、役職 (job title) に責任を負わせないこと
代わりに、それらの肩書きを可能な限り広く適用できるようにする
組織の公式な役職は変更頻度が低い → 役職と日々の責務を切り離す
公式な役職は、非公式な役割の公式な境界として機能する
スクラムで全員が単なるメンバーなのも、これが理由
これは generalizing specialist の考え方を後押しするもの
必要なものは、少数の公式の役職と、非公式の役割がどの公式の役職に合うのかのガイドライン
チームのリーダーは、ときに 「リード」 や 「チーフ」 と呼ばれる (テックリードとかチーフアーキテクトとか)
複数の分野でリードする人がいる場合、分散型非公式リーダーシップ (distributed informal leadership) と呼べるかも
これらはマネジメント層を含まない → 組織の適応性を高める
チームは、多数の人を 1 つのエンティティとして認識できるようにするので便利 (チャンク化) チームの境界の管理はマネジャーの責任として重大な部分
境界管理の 3 つの側面
チームを構築する方法
チームの自己選択はエンパワメントの成熟度が高い場合に可能かもしれないが、めったには見られない
マネジャーとして、チーム形成についての制約を定義して、議論すべき
チームと個人の関係
1 人 1 チームが原則 (でなければパフォーマンスが悪化する)
チームの経時変化
チームが長く存続するほどパフォーマンスが向上する
チームに最適な人数
アジャイル界隈では 7 ± 2 とよく言われる
ただし、8 人だけはうまくいかない
環境やメンバーの個性によって最適な人数は変動する
本書では、大体の場合にうまくいく人数として 「5」 を推奨
人をどの軸でまとめるか : 機能軸か事業軸か
日常的なコミュニケーションは、事業軸の方が密
欠点として、一つの機能分野における標準や手法などの同期にコストがかかる
他には多くの利点がある
複数チームの調整の方法
Fred Emery が 2 つの方法を命名
first design principle (DP1) : チームより 1 段上の層にいる人 (ラインマネジャーかラインマネジャーに任命された人) が決定する second design priciple (DP2) : チーム自身で、調整を行う
基本的には DP2 が良い
DP1 は、DP2 がうまく機能しない場合 (コンピテンシーの問題が残っているなど) にのみ選択すると良い
組織スタイルの選択について
「機能組織は階層構造型で、機能横断組織はネットワーク型」 と考えるのは誤り
どちらも何かしらチーム間での調整が必要であり、その調整をどうやっているのかが重要 (上の DP1 と DP2 の話)
(機能組織 or 機能横断組織) × (DP1 or DP2) の 4 通りがある
一般論としては、機能横断組織が機能組織より良く、DP2 の方が DP1 より良い
成熟度などによっては機能横断の DP2 は問題が増える可能性もあるので、マネジャーが最適なスタイルを選択
重要なのは、チームが顧客 (社内でも社外でも) に価値を提供すること
それがないと……
機能チームは、局所最適化を犯しやすい (事業全体の効率を悪くしてしまう)
機能横断チームは、独自のプロジェクトに最適化してしまう可能性がある (事業全体に悪影響を及ぼすこともある)
一般論に反して、スペシャリストの機能チームを組織することが有用なこともあるはず
その場合に気を付けること
スペシャリストチームとのインターフェイス : スペシャリストチームの人に定例に出てもらうとか
スペシャリストチームは、プロジェクトチームを部下とみなすのではなく顧客とみなすこと
逆に、プロジェクトチームはスペシャリストチームが価値を提供しているのか見極めること
他チームとのコミュニケーション総量はどんな構造でも同じなので、ちょうどよい他チームとの接点数にすること
「機能横断組織が必要だが、機能ごとの連携も必要」、という要求に答えられる良い妥協案
スペシャリストチームは自己組織化の結果として作られることもある
効率性と有効性が高い
スペシャリストチームがサービス提供者であり、プロジェクトチームが消費者
PMO チームがあるならそれも同様で、あくまで PMO は支援する立場であり、管理者的に振る舞うものではない 階層は必要だが、悪用される可能性もある
組織化の目的はコミュニケーション量を減らすことなので、組織化そのものがコミュニケーションにとっては害
承認は階層で、通信はネットワークで
階層には機能がある
マネジメントレイヤーは、組織構造に価値を加えなければならない
例えば……
異なる時間軸で考える (最下層では 1 日 ～ 3 ヵ月の問題を、次の層は 3 ヵ月 ～ 1 年、次の層は 1 年 ～ 3 年)
採用や戦略的提携、予算のバランシングなど
問題がいくつか
2 人のマネジャー間の力関係による士気の問題
適切な実装では、権限のラインは 1 つ (ラインマネジャー)
プロジェクトマネジャーは、チームにサービスを提供 (チームの管理ではない)、プロジェクトを管理する (人の管理でもない)
大規模プロジェクトは失敗しがち
ボトムアップによる適応性
panarchy は、協働 (collaboration) と権限 (authority) の重複したネットワーク
nobuoka.icon これ、本当にパナーキーの概念にあってるのかな
権限について複数の源を持つこともできるし、自分たちがそういうチームになることもできるし、チーム内ですべてを決めることもできる
ラインマネジメントだけはチームでは決められない
多くの組織では人々は適切な情報を得られていない → そのため、それを推測したりする
情報にアクセスできるようにする必要がある
一般論としては、給与も含めて、全部公開するのが良い
が、文化はすぐには変えられないので、マネジャーから徐々に
習慣や文化を広めるには？ → 他の人からも見えるようにする (見えるプロセスは情報発信機 (information radiator))
人をつなげること
適応性
重要なことは、組織が変化していく能力を高めること
そのために、組織の仕様は最小限であることが望ましい
“barely sufficient” の原則 (“barely sufficient” principle) を適用することで、チームに自己組織化の柔軟性と自由を与える
どうなると良い？ : メンバーが組織変更に不満を言うのではなく、新しい組織構造を提案する状況